31 FPS。

看到這個數字的時候，其實滿開心的。

前面從 2.7 FPS → 31 FPS，Qualcomm HTP/NPU 確實把 AI Inference 加速起來了。

我心裡想：

好了，AI 應該可以用了吧？

結果下一個問題馬上來了。

「那如果我有 3 支 Camera 呢？」

這才發現，

31 FPS 只是開始。

一支 Camera 跑得快，不代表三支也跑得動

一支 Camera 的 Pipeline：

Camera
  ↓
Decode
  ↓
Pre-process
  ↓
HTP / NPU
  ↓
Post-process
  ↓
Event

變成三支之後：

Camera 1 ─┐
Camera 2 ─┼→ Decode → Pre-process → NPU → Post-process → Event
Camera 3 ─┘

這時候大家開始搶資源：

CPU、NPU、Memory、Video Decode、Memory Bandwidth。

所以我開始不再只看 FPS。

而是盯著：

到底是哪一個先滿？

結果，NPU 開始有感了

在 1080p 多串流測試時，我們看到 NPU 使用率大約來到：

70～90%。

Node-RED 這類 Application CPU 約：

20～30%。

這時候就很有意思。

CPU 看起來還沒爆。

但 NPU 已經開始接近負載上限。

也就是：

不是 CPU 不夠，而是 AI 算力開始成為瓶頸。

這時候規格表上的數字就不夠用了

QCS6490 有很漂亮的 TOPS。

規格也會告訴你 Camera / Session 可以到多少。

但 PM 不能直接拿這個數字寫：

「我們支援 3 支 AI Camera。」

因為我們真正的 Pipeline 還包含：

1080p RTSP
 ↓
Decode
 ↓
Pre-processing
 ↓
AI Inference
 ↓
Post-processing
 ↓
Rule
 ↓
Event

只要其中一段撐不住，

整個 Application 就會開始掉效能。

所以在我們目前這個 PoC、Model 和 Pipeline 下，實際比較保守的結果是：

穩定 AI inference 約 1～2 路。

這不是說 QCS6490 最多只能跑 1～2 路。

而是：

在我們目前的產品條件下，實際驗證到的 Operating Envelope。

這兩件事情差很多。

我突然發現，AI PM 最後要定義的不是「31 FPS」

而是：

Model
   +
Resolution
   +
FPS
   +
Stream Count
   +
CPU / NPU
   +
Memory
   +
Stability

最後變成一句客戶聽得懂的話：

「在這個 Model、解析度和 AI Pipeline 下，我們可以穩定支援幾路 Camera？」

這才是產品規格。

Day 10 的結論

2.7 FPS → 31 FPS，證明我們把 AI 加速起來了。

但：

31 FPS → Multi-Stream

才真正開始碰到 Edge AI Product 的難題。

因為單路 Benchmark 證明的是：

「它跑得快。」

Multi-Stream 驗證的則是：

「它真的能拿來用。」

而下一個問題更麻煩：

如果我們已經知道一台 Edge Device 的算力有限，那到底該讓客戶自己選 Model、Camera 和 AI Rule 嗎？

這就會進入下一階段：

從「把 AI 跑起來」開始走向「把 AI 做成產品」。